The present invention relates in general to the field of computers and similar technologies, and in particular to software utilized in this field.
In an IDE type of environment, assembling an end product such as a HyperText Markup Language (HTML) page or a JAVA® Server Page (JSP) object often requires input from multiple components. The components may be, for example, data, controls/widgets, style/look-and-feel, etc. For example, in order to build a data table in a page in an Integrated Development Environment (IDE) using an application technology such as JavaServer Faces (JSF), a user needs to first drop the data table control to the page, which causes an empty table to be created and visualized in the editor page (pane; window) of the IDE. Then a data definition is dropped into the editor page, which will cause the data table to be “bound” to a data definition object. Essentially this particular operation involves two components that are interwoven together to form a concrete configuration (i.e., a “data-bound” JSF table).
The same result in the example above can be achieved by reversing the order of the components: the data will be dropped to the page first, then the user determines what controls to create (bind) for the data object, by way of a prompt dialog or drag and dropping the desired control onto the visualized data object. Components can be put together in different combinations in order to form more sets of concrete configurations. For instance, the control component, in addition to being applied with the data component, can be applied with a style/look-and-feel component to form concrete control(s) with the desired style/look-and-feel.
Consider then the just described prior art process for constructing a data table illustrated in FIG. 1. As shown in IDE 100, a data table 102 in the editor 104 is created by first pulling the template “Data Table” from the menu in the palette view 106, then binding the template “Data Table” to a data definition (“getEmpListParams(REQUEST_BAPI_ABSENCE)”) visualized in “Page Data” view 108, and then applying the “.form” style class from the “Styles” view 110. As depicted, this requires three separate drag and drop operations to create the table 102. This is problematic to the process of creating the table 102 since, once the table 102 is dropped and visualized in the editor 104, the table 102 will contain multiple child elements that can also be the target of subsequent data binding and style binding operations. Therefore, during any subsequent drop operation it is very important that the cursor be at the right location to indicate that the target of the drop is the entire table as opposed to any child element. This can be tricky from the user's point of view and requires careful implementation from the tooling developer's point of view. Thus, a serious limitation to the drag and drop operation described above is that it supports only one component at a time. Furthermore, a drawback of the described prior art is that the order of the drag and drop operations matters, since performing these operations in a particular order may cause unintended results. For example, if a table is dropped first, and then data is dropped on top of the table, this may unintentionally cause a table column to become the target of the data drop (or a style rule drop), rather than the entire table.